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At  Some  Point,  Your  Organization  Will 
Incorporate  CMMI  into  Your 
Improvement  Program 

A  primary  assumption  is  that  this  audience  is  interested  in 
moving  from  a  SW-CMM  based  improvement  to  one  based 
on  CMMI 

I’m  NOT  assuming  that  you  will  necessarily  be  making  this 
transition  right  now  or  in  the  next  six  months 
•  The  approaches  in  this  seminar  should  be  applicable  at 
any  point  that  you  decide  to  begin  adoption  of  CMMI 
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You’ll  be  Increasing  the  Scope  of  Your 
Improvement  Effort 

I’m  assuming  that  you  are  planning  to  take  advantage  of 
the  more  general  scope  of  the  CMMI  framework  and  that 
you’re  thinking  about  including  parts  of  the  organization 
who  have  NOT  been  part  of  your  SW-CMM  improvement 
effort 

•  Who  else  gets  involved  depends  on  your  business 
context 

•  I’m  also  assuming  you’re  basing  the  decision  on  who  to 
include  based  on  the  business  benefits  you  expect/need 
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It’s  Been  Awhile  Since  You  Started 
Your  Improvement  Effort 

Many  of  you  have  been  involved  in  SW-CMM  based 
improvement  for  multiple  years,  multiple  cycles  of 
improvement 

•  Those  that  began  the  improvement  effort  may  have 
moved  on  to  other  roles  and/or  other  organizations 

•  Those  who  were  in  leadership  in  the  organization  at  the 
beginning  of  your  improvement  effort  may  have  moved 
on  to  other  roles  and/or  other  organizations 

“Corporate  memory”  on  what  it  took  to  get  you  to  where  you 
are  today  may  be  sparse 
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How  does  this  audience  fit  with  my 
assumptions?--1 

How  many  already  have  begun  adoption  of  CMMI? 

How  many  believe  your  organization  will  NOT  adopt  CMMI 
within  the  next  3  years? 

How  many  are  planning  to  include  at  least  one  more  group 
in  their  organization  in  their  CMMI  adoption? 

How  many  are  planning  to  keep  the  scope  (organization- 
wise)  of  their  improvement  the  same  if/when  they  adopt 
CMMI? 
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How  does  this  audience  fit  with  my 
assumptions?--2 

How  many  have  been  involved  in  CMM-based  improvement: 

•  <1  year 

•  1  to  3  years 

•  3  to  5  years 

•  5  to  10  years 

•  >10  years 

How  many  of  you  know  or  have  access  to  those  who  were  the 
champions  or  leaders  of  your  process  improvement  effort  at  the 
beginning? 

How  many  of  you  know  or  have  access  to  those  who  were  the 
sponsors  of  your  process  improvement  effort  at  the  beginning? 
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Sponsored  by  the  U.S.  Department  of  Defense 
©  2003  by  Carnegie  Mellon  University 


Version  1.0 


page  9 


Carn^eMdlon 

Software  Engineering  Institute 

CMMI  Structure  or  Content 

Go  to  the  SEI  web  site  to  find  out  about  classes  in  CMMI 
held  at  the  SEI  or  by  our  transition  partners 

There  are  several  books  now  available  describing  the 
model  with  suggestions  for  implementation 
•  Stay  tuned  -  if  you  haven’t  seen  the  one  you  like  yet,  my 
guess  is  there  will  be  at  least  half  a  dozen  more  in  the 
next  year  to  two  years 
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The  Exact  “Recipe”  for  Adopting  CMMI 


IDEAL®  and  other  improvement  life  cycles  provide  relevant 
guidance  on  how  to  organize  and  implement  an 
improvement  effort 

•  The  techniques  and  approaches  included  here  should 
complement  and  integrate  with  most  improvement  life 
cycles 
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Finding  a  Partner  to  Work  With  Today 

With  this  many  people,  doing  exercises  to  explore  how 
some  of  the  techniques  work  is  a  challenge,  but  not 
impossible 

Easiest  way  I’ve  found  is  to  ask  you  to  pair  up  with  the 
person  sitting  next  to  you  for  guided  discussion  sessions 
throughout  the  seminar 

•  Might  be  someone  you  know,  might  not 

•  Should  work  ok  either  way 

So,  for  first  exercise,  pair  up  with  the  person  next  to  you 
(from  here  on  known  as  your  partner)  to  talk  about  why  you 
came  to  the  seminar  today  (5  minutes  or  so) 
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From  the  Abstract.... 

“The  preliminary  data  indicates  that  many  adoption  issues 
are  not  unique  to  commercial  software,  IT,  and  IS 
organizations.  The  same  issues  were  typically  reported  by 
organizations  in  different  domain  areas.  The  data  also 
confirms  that  most  organizations  believe  that  CMMI  is 
adequate  for  guiding  their  process  improvement  activities. 
From  the  data  we  also  learned  that  organizations  benefited 
from  prior  investment  in  process  improvement  as  they 
adopted  CMMI.  ” 
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Two  Areas  of  Further  Investigation 

Appraisals 

•  A  number  of  negative  comments  and  issues  documented 
related  to  CMMI  appraisal  methods 

CM  Ml  Representations 

•  An  area  of  concern  and  confusion  for  many 
organizations 
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Interesting  Tidbits  from  the  Interpretive 
Guidance  Data 

10%  of  responding  orgns  have  chosen  not  to  adopt  CMMI 
62%  of  responding  orgns  have  CMMI  adoption  in  progress 
or  already  institutionalized 

35%  of  respondents  believe  CMMI  is  “almost  always” 
adequate  for  guiding  their  process  improvement 
42.2%  of  respondents  believe  CMMI  is  adequate  for 
guiding  their  process  improvement  “more  often  than  not” 

76%  of  respondents  agreed  or  strongly  agreed  that 
adopting  CMMI  would  help  them  to  leverage  earlier 
investments  in  process  improvement 
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Interesting  Tidbits-2 

42%  of  respondents  agree  or  strongly  agree  that  the  cost  of 
adopting  CMMI  is  impeding  their  adoption  of  CMMI 

On  the  other  hand.... 40%  of  respondents  disagree  or 
strongly  disagree  that  the  cost  of  adopting  CMMI  is 
impeding  their  adoption  of  CMMI 

58%  of  respondents  disagreed  or  strongly  disagreed  that 
they  had  difficulty  in  mapping  their  processes  to  CMMI 

48%  of  respondents  agree  or  strongly  agree  that  having  a 
choice  between  two  model  representations  has  been 
helpful  to  them 

23%  disagreed  or  strongly  disagreed  on  the  same  question 
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A  Sampling  of  Adoption  Support  Needs 
Cited  in  the  Questionnaire 

In  answer  to  “What  else  could  be  done  to  facilitate  your 
adoption  of  CMMI?”  here  are  a  sample  of  answers  from 
respondents: 

•  More  flexibility  in  the  implementation  and  assessment 
process 

•  Courses  by  Process  Areas 

•  Publication  of  business  cases  and  adoption  stories 

•  More  simple,  but  complete  examples  of  processes  and 
data  items 

•  “I  think  you  need  to  talk  to  our  executives” 
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You  Know  More  Than  You  Think  You 
Know.... 

About: 

•  Communicating  benefits  of  PI  to  senior  management 

•  Working  with  practitioners  and  managers  to  produce 
workable  practices  that  adhere  to  your  model  of  choice 

•  Developing  useful  process  guidance 

•  Developing  and  sustaining  a  Process  Asset  Library 

•  Developing  and  deploying  useful  measurements 

•  Selecting  SEPG  staff  and  helping  them  to  be  effective 

•  . lots  of  other  particulars  of  process  improvement 

Most  important,  you  know  what  does  AND  DOESN’T  work 
to  communicate  about  and  support  implementation  of 
process  improvement  in  your  organization 
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Does  this  Apply  to  CMMs? 

-  "Radical  innovation  is  the  process  of 

introducing  something  that  is  new  to  the 

organization  and  that  requires  the 

development  of  completely  new  routines, 

usually  with  modifications  in  the  normative 

beliefs  and  value  systems  of  organization 

members.  "  —  Nord  and  Tucker,  Routine  and  Radical 
Innovations,  1987 

“Radical  innovations”  are  the  topic  of  the  research 
area  of  technology  transition,  a  continuing 
research  focus  of  the  SEI 
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What  do  you  think? 

If  you’re  new  to  model-based  improvement: 

•  What  do  you  think  (based  on  your  current  knowledge  of  CMMI) 
that  CMMI®  adoption  will  require  in  terms  of: 

-  development  of  new  routines  (procedures)? 

-  modifications  in  the  norms,  beliefs,  and  values  of 
organization  members? 

If  you’ve  been  using  another  model  as  your  improvement  base, 
how  different  are  your  answers? 

-  I’d  expect  you  to  still  have  to  develop  “new  routines” 

-  I  would  expect  that  many  of  the  norms,  beliefs,  and 
values  are  similar  between  another  model  (i.e.,  SW- 
CMM®)and  CMMI) 
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Treating  Your  Adoption  as  a 
Technology  Transition 
Effort  May  Make  Sense 

In  the  technology  transition  arena,  we  use  some  of  the 
same  and  some  different  tools  as  the  process  improvement 
community 

My  perspective: 

•  Use  whatever  tools/techniques  you  find  useful  in  your 
environment 

•  Sometimes  thinking  about  things  from  a  different  but 
related  viewpoint  opens  up  new  useful  directions 


©  2003  by  Carnegie  Mellon  University 


Version  1.0 


page  23 


CctfiicgieMeilan 

Software  Engineering  Institute 

Factors  In  Considering  Adopting 
Complex  Technology 

Primary  reasons  organizations  delay  investing  in  new 
innovations . 

•  prior  technology  drag-legacy  systems  and  work  procedures 
based  on  them 

•  irreversibility  of  investments-short  "useful  life"  for  large 
amount  of  money! 

•  sponsorship-getting  and  keeping  it  are  a  challenge  for 
dynamic  organizations 

•  expectations-what  the  technology  can  deliver  vs.  what  is 
promised/expected 

(adapted  from  Fichman  and  Kemerer, ,  “Adoption  of  Software  Engineering  Process  Innovations:  The  Case  of  Object 
Orientation,”  Sloan  Management  Review,  Winter  1993,  pp.  7-22.) 

Which  of  the  above  affect  your  consideration  of  transitioning  to 
CMMI? 
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Observations  on  Technology 
Transitions  We’ve  Witnessed 

Each  transition  is  highly  situational  and  its  strategy  will  be 
unique  to  that  situation  and  context.  However,  some  basic 
concepts  can  be  applied  in  generating  that  strategy: 

•  Multiple  dimensions  have  to  be  addressed 
simultaneously  to  achieve  success,  not  just  the 
technology  content 

•  Different  audiences  respond  differently  as  they  are 
introduced  to  the  technology 

•  Acceptance  of  a  new  technology  does  not  happen  in  a 
linear,  predictable  fashion,  no  matter  how  pretty  the 
charts  look! 
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Observations  on  Technology 
Transitions  We’ve  Witnessed--2 

There  are  both  different  “levels  of  diffusion” — the  breadth  of 
technology  acceptance — and  “levels  of  use”  (or 
infusion) — the  degree  to  which  the  technology  becomes 
embedded  in  the  organization’s  governing  and  social 
practices 

Different  “mechanisms”  are  useful  at  different  points  in  the 
transition  to  address  different  implementation  issues  with 
different  audiences 

Most  organizations  are  very  poor  at  transferring  what 
they’ve  learned  from  one  technology  transition  effort  to 
another 
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Key  Elements  in  Successful  Transition 
from  One  Technology  to  Another 

•  Understanding  the  goals  of  the  different  roles  involved  in 
the  transition  and  how  they  relate 

-  Understanding  the  target  adoption  population  (market) 
for  the  technology 

-  Value  networks  is  a  technique  we’ve  developed  to 
support  understanding  how  different  stakeholders  in  an 
adoption  interact 

•  Understanding  the  characteristics  of  the  technology 

-  What  problems  is  it  intended  to  solve?  Are  those  the 
ones  we’re  using  it  for? 

-  How  well  does  it  match  the  needs  of  adopters  who  have 
a  need  to  solve  those  problems? 

-  How  “transitionable”  is  the  technology? 


©  2003  by  Carnegie  Mellon  University 


Version  1.0 


page  27 


("timegieMellon 

Software  Engineering  Institute 

Key  Elements  in  Successful  Transition 
from  One  Technology  to  Another--2 

•  Understanding  what  will  be  needed  to  make  the 
technology  “work”  for  different  types  of  adopters 

-  Transition  mechanisms  for  the  technology 

-  Work  practice  and  other  changes  required  in  the 
adopting  organization 

•  Identifying  and  mitigating  the  different  types  of  risks 
identified  as  part  of  understanding  all  the  above 
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Understanding  Your  Audience  for 
the  Transition 


These  are  the  “nodes”  in  your  value  network. 

Key  questions  in  moving  forward  with  CMMI: 

Which  roles  in  your  organization  will  need  to  change 
something  in  their  behavior/ attitudes/ values  to  adopt 
CMMI? 

What  things  make  these  groups  more  or  less  likely  to 
change? 
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Different  "Adopter  Types"  Move 
Through  Adoption  at  Different 
Speeds 


Depending  on  many 
factors,  early  adopters 
for  one  type  of 
technology  could  be 
late  majority/laggards 
for  another  (and  vice 
versa!) 

Where  are  your 
different  stakeholders 
with  regard  to  major 
process  changes? 


“The  Chasm” 


Innovators  Early  Majority 

‘Techies”  I  “Pragmatists” 


Laggards 

“Skeptics” 


Early  Adopters  Late  Majority 

“Visionaries”  “Conservatives” 


Source:  Geoffrey  Moore,  Crossing  the  Chasm,  1991 
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Innovators 

Gatekeepers  for  any  new  technology 

Appreciate  technology  for  its  own  sake 

Appreciate  architecture  of  technology 

Will  spend  hours  trying  to  get  technology  to  work 

Very  forgiving  of  poor  documentation,  slow  performance, 
incomplete  functionality,  etc. 

Helpful  critics 
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Early  Adopters 

Dominated  by  a  dream  or  vision 

Focus  on  business  goals 

Usually  have  close  ties  with  “techie”  innovators 

Match  emerging  technologies  to  strategic  opportunities 

Look  for  breakthrough 

Thrive  on  high  visibility,  high  risk  projects 

Have  charisma  to  generate  buy-in  for  projects 

Do  not  have  credibility  with  early  majority 
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Early  Majority 

Do  not  want  to  be  pioneers  (prudent  souls) 

Control  majority  of  budget 

Want  percentage  improvement  (incremental,  measurable, 
predictable  progress) 

Not  risk  averse,  but  want  to  manage  it  carefully 
Hard  to  win  over,  but  are  loyal  once  won 
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Late  Majority 

Avoid  discontinuous  improvement  (revolution) 

Adopt  only  to  stay  on  par  with  the  rest  of  the  world 

Somewhat  fearful  of  new  technologies 

Like  pre-assembled  packages  with  everything  bundled 
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Laggards 

“Nay  sayers” 

Adopt  only  after  technology  is  not  recognizable  as  separate 
entity 

Constantly  point  at  discrepancies  between  what  was 
promised  and  what  is 

Hmmm . are  you  seeing  some  of  this  behavior  from  those  invested  in 

SW-CMM? 

When  a  technology  becomes  “ overadopted ,  ”  sometimes  people  who 
would  be  innovators  in  other  contexts  act  more  like  laggards! 
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Different  Parts  of  the  Organization 
Learn  at  Different  Rates 

....because  of  their  adoption  inclinations,  time  available  to  pay 
attention  to  the  new  technology,  management  direction  --  there 
are  lots  of  factors  that  can  impact  how  quickly  one  segment  of 
the  organization  adopts  vs.  another 

What  happens  if  the  practitioners  adopt  early  and  quickly,  and 
program  management  doesn't  have  time  to  pay  attention  and 
adopts  more  slowly? 
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Value  Networks:  A  Different  Way  of 
Looking  at  Your  Stakeholders 


Value  Networks  are  a 
way  to  start  looking  at 
the  exchanges  that 
need  to  occur  between 
different  roles  within  a 
“marketplace”  or  group 
of  stakeholders 
•  Example  here:  a 
value  network  for 
INTRo,  an  SEI 
technology 
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Applying  Value  Networks  to  CMMI 

Identify  nodes  in  the  network: 

•  Stakeholder  groups  (preferably  role-based)  who  need 
something  from  the  CMMI  transition  team 

-  Pilot  projects 

-  Project  managers 

-  Senior  management  steering  groups 

-  External  customers 

-  Internal  customers 


•  Stakeholder  groups  who  have  something  that  the  CMMI 
transition  team  needs 

-  External  consultants 

-  Internal  consultants 

-  Training/education  group 

-  Projects 

-  SEI 
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Identify  “What’s  Exchanged” 
Between/Among  the  Stakeholders 

•  Data... 

•  Resources  to  get  things  moving... 

•  Special  skills... 

•  Dollars... 

•  Project  measures... 

•  Lessons  learned... 

•  Process  assets... 

•  Process  appraisal  results... 
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Exercise 


Program 

Managers 


NOTE:  Interactions  occur  both  between  the  improvement  and  stakeholders 

as  well  as  among  the  stakeholders 
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Instructions — 7  minute  limit  (2  minutes  working 
alone,  5  minutes  discussion  with  partner) 

Think  of  the  roles/groups  that  are  stakeholders  in  your 
organization  in  your  SW-CMM  (or  whatever  model  you’re  using) 
improvement  effort.  Write  down  the  5  most  important  stakeholder 
groups. 


Share  your  list  with  the  person  next  to  you  and  vice  versa 

•  If  you  both  work  in  the  same  organization 

-  Note  the  groups  that  are  the  same  in  terms  of  the  “top  5” 

-  Note  the  groups  that  are  missing/different  for  each  list 

•  If  you  work  in  different  organizations 

-  Note  the  groups  that  are  the  same  in  function,  even  if  you 
use  different  names  for  them 

-  Note  the  groups  that  are  different  for  each  list 
In  both  cases... 

•  What  additional  groups  “come  up”  as  part  of  your 
conversation? 

•  Which  of  these  groups  are  still  important  to  you  in  moving  to 


CMMI? 
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Now  Let’s  Deal  with  Value  Exchanges  (10  minutes 
working  alone,  5  minutes  discussing  with  partner) 

Decide  on  5  of  the  stakeholder  groups  you  want  to  focus  on  for 
value  exchanges — sketch  a  diagram  with  CMMI  Transition  Team 
in  the  center  and  the  other  stakeholders  surrounding  them 

For  each  group: 

•  Think  about/write  down  what  (in  the  abstract)  you  think  the  key 
value  is  that  is  provided  by  that  group  to  the  CMMI  transition 
team 

•  Think  about/write  down  what  you  think  the  key  value  is  that  the 
CMMI  transition  team  provides  to  that  stakeholder  group 

•  Think  about/write  down  important  values  you  think  are 
exchanged  among  the  stakeholders  themselves 

After  10  minutes,  discuss  your  results  with  your  partner 

•  How  similar/different  are  the  results? 
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What  To  Do  In  Real  Life  with  This... 

We  have  been  postulating  and  guessing  about  who  the 
stakeholders  are,  what  they  want,  what  they  can  offer  the 
team 

There  IS  a  way  to  get  validation  of  your  guesses: 

•  TALK  to  representatives  of  the  stakeholder  groups  and 
confirm  your  hypotheses 

You  can  get  somewhat  detailed  with  this,  or  stay  abstract 
for  awhile — beware  of  getting  “stuck  in  the  weeds” 

Once  you  have  your  value  network  identified,  you  can  use 
some  of  the  other  techniques  to  think  about  what  kinds  of 
transition  mechanisms  will  be  needed  to  help  each  one 
transition  productively  to  CMMI  (we’ll  talk  about  this  next) 
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Leveraging  Your  SW-CMM 
Transition  Mechanisms 
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Understanding  Some  Major  Shifts 


Source:  Patterson  &  Conner,  “Building  Commitment  to  Organizational  Change”,  1982. 
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A  Success-Oriented  View  the  SEI  Finds  Helpful 


Adapted  from  Patterson  &  Conner,  “Building  Commitment  to  Organizational  Change”,  1982. 
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Enabling  Movement  From  One  Stage 
to  Another  through  Transition 
Mechanisms 


Innovators  and  Early  Adopters  will  tend  to  “make  their  own” 
transition  mechanisms  and  make  do  with  what's  available 
from  the  technology  producer 

Early  and  Late  Majority  adopters  expect  many  of  these 
mechanisms  to  be  readily  available  for  them  to  acquire 
without  development 
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More  Detail  on  Transition 
Mechanisms 

The  transition  mechanisms  that  follow  fulfill  two  purposes: 

•  for  the  technology  producer  (e.g.,  the  CMMI®  Product 
Team),  many  of  the  mechanisms  in  Contact,  Awareness, 
and  Understanding  are  used  in  their  marketing  kits 

•  for  the  technology  adopter,  technology  producer 
materials  need  to  be  adapted  to  help  “sell”  the 
technology  to  the  intended  users 

Note  that  not  all  of  these  are  actually  “products”;  some  of 
them  are  events  or  activities 

These  are  a  general  set  of  mechanisms  that  could  be  used 
in  your  organization;  which  ones  are  right  for  you  depend 
on  your  organization’s  context  and  culture 
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Tools  for  Contact  and  Awareness 

Communication  Devices 
“Elevator  speech” 

Standard  45  minute  pitch  -  road  show 
FAQ 

Magazine  articles 
Conference  briefings 

Flash  cards  with  objectives,  benefits,  URL,  etc. 

Web  site  devoted  to  the  technology,  with  links  and  dialogue 
Successful  ROI  stories,  case  studies 
Focus  on  concept,  not  the  buzzword 
Executive  summary  of  policy 
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Understanding 

Communication  and  education 
One-day  seminars,  symposia  for  various  vendors 
Detailed  case  studies 
Technical  brief 

Identify  and  authorize  champions 

Identify  stakeholder  roles,  responsibilities,  and 
interrelationships 
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Trial  Use 

Questions  to  consider:  How  big  do  you  need  to  be  to  consider 
pilots?  How  do  small  organizations  conduct  pilots? 

Pilot  Programs 

Carefully  identify  a  couple  of  focused  pilots  (or  “experiments”) 

Define  incentives  for  pilot  participation 

Small  working  group  to  support  pilots 

Special  authorities  for  pilots 

Document  pilot  results 

Protect  and  support  the  pilots 

Communication,  education,  and  support 

Define  measures  of  success 

2-3  day  course  for  pilots  and  interested  others 
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Trial  Use-2 

Users  Group  (may  be  external,  e.g.,  SPINs)  -  share 
experiences 

Transmit  lessons  learned  from  innovators  and  early 
adopters 

Case  exercise  for  transitioning  from  one  set  of  work 
practices  to  one  with  the  new  technology  support 

Technology  use  startup  and  coaching 

Identify  barriers  and  workarounds 
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Adoption 

Strong  set  of  incentives;  rewards  and  consequences 

Refined  guidance  on  CMMI®  usage  choices  and  implementation 

Education  -  mature  courses,  modularized  for  Just-In-Time 
delivery 

In-Process  Aids 

Repository  on  business  cases  and  lessons  learned 

Sample  implementation  plan  with  impact  analysis 

Job  aids  -  process  guides,  start-up  guides,  coaching,  JIT  training, 
guidebooks 

Identify,  draft  needed  policies  or  standards 

Ensure  that  CMMI  sustainment  infrastructure  is  in  place  and 
resourced 
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Institutionalization 

Fully  realized  curriculum  of  training  for  different  types  of 
users 

New  employee  training/orientation 
Stability  in  leadership  use  of  CMMI®  data 
Grandfathering  vs.  cutover  policy 

Continuous  improvement  to  adoption  artifacts  (guides,  etc.) 
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SEI’s  “What  Works,  What’s  Needed” 
Workshop 

A  workshop  held  in  May  2001  with  early  adopter  organizations  for 
CMMI 

Purpose:  To  determine  what  transition  mechanisms  were 
enablers  of  the  transition  to  CMMI,  and  also  to  understand  what 
transition  mechanisms  early  adopters  believed  needed  to  be 
developed 

Report  from  the  workshop  is  available  at  the  SEI  web  site 
Publications  page 

Next  two  slides  summarize  which  communication  mechanisms 
(generally  focused  on  Contact,  Awareness,  Understanding)  and 
implementation  mechanisms  (generally  focused  on  Trial  Use, 
Adoption,  and  Institutionalization)  were  cited  in  the  workshop 
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Communication  Mechanisms 

Primarily  focus  on  moving  between  Contact  Awareness,  and 
Awareness  Understanding 

CMMI®  Examples  from  1st  CMMI  “What  Works,  What’s  Needed”  Workshop: 

What  Works:  Contact  /  Awareness 

•  "Think  CMMI"  promotional  program;  reference  cards;  promotional  materials  (14) 

•  Translations  of  SEI  Material  into  local  language  (8) 

•  Establish  multiple  communication  channels  (4) 

•  CMMI  awareness  briefings/forums  (3) 

What  Works:  Understanding 

•  Self-assessment;  gap  analysis;  mini-assessments;  class  B  &  C  assessments 
that  relate  gaps  to  the  organization’s  processes  (20) 

•  Chart  on  how  processes  are  responsibility  of  different  roles/across  organization 
boundaries  (11) 

•  Poster  on  CMMI  (7) 

•  Transition  Road  Map  (7) 

•  CMMI  action  plans  (4) 

•  BoF  on  focused  topics  (4) 

-  Note:  cross-model  maps  didn't  get  many  votes! 
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Implementation  Support  Mechanisms 

Primarily  support  moving  from  Understanding  Trial  Use,  Trial  Use  Limited 
Adoption,  Limited  Adoption  Institutionalization 

Example  Implementation  Support  Mechanisms  from  WW,WN  Workshop  for 
CMMI®: 

What  Works:  Trial  Use 

•  Integrating  QA  to  measure  PI  progress  (8) 

•  Link  QA  process  to  CMMI  (8) 

•  Transition  Strategy  SW-CMM-->CMMI  (8) 

•  Pilot/trials  in  non-development  areas  (7) 

•  Example  CMMI  PI  budget  (5) 

What  Works:  Adoption 

•  Role-based  training  (24) 

•  Tailoring  guidance/strategies  for  different  organizational  contexts  (23) 

•  Transition  steering  group  (10) 

•  ROI  trend  data  (9) 

•  Integrating  all  disciplines  into  the  process  group  (8) 

What  Works:  Institutionalization 

•  CMMI  Best-Practice  Based  Templates/Checklists/Assets  (22) 

•  Integrating  Process  Review  into  Project  Management  Review  (14) 
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Exercise:  Thinking  About  What 
You  Can  Reuse  and  How 
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Miniature  “What’s  Worked”  Exercise  (5  minutes 
working  alone,  5  minutes  discussing  with  partner) 


If  you’re  moving  from  an  existing  improvement  effort  to  CMMI,  you 
already  have  invested  a  significant  amount  of  time,  effort,  and  money  into 
building  transition  mechanisms  based  on  your  previous  model 

•  Some  of  them  could  be  used  with  minimal  change  for  CMMI 

•  Some  of  them  would  take  a  good  bit  of  rework  to  be  useful 

•  Some  aren’t  worth  trying  to  “save”  -  you’re  better  off  starting  from 
scratch 

Think  about  the  mechanisms  you’ve  successfully  used  with  your  previous 
improvement  effort 

Using  the  table  on  the  following  slide  as  a  guide,  spend  5  minutes  listing 
mechanisms  you  might  think  about  reusing  for  CMMI 

Discuss  the  similarities  and  differences  between  your  table  and  your 
partner’s. 
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What’s  Worked/How  Much  It  Will 
Take  to  Reuse 


Rework  Effort 

P-C  Stage  l 

Minimal 

Medium ,  but 
worth  it 

Too 

much — not 
worth  reusing 

Contact 

Awareness 

Understanding 

Trial  Use 

Limited  Adoption 

Institutionalization 
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What  do  you  do  with  the  results? 

Use  results  of  analysis  to  estimate  (at  least  some)  of  the 
resource  needs  for  moving  from  one  model-based 
improvement  to  another 

•  It’s  typical  to  assume  “everything”  can  be  reused,  but  a 
little  thought  often  leads  to  a  different  conclusion 

•  Different  people  will  have  different  ideas  about  level  of 
reuse  achievable 

-  highlighting  those  differences  can  help  you  to  refine 
your  ideas 

•  How  mechanisms  were  architected  the  first  time  around 
sometimes  determines  how  easy  they  are  to  reuse 

•  Giving  sponsors  “data-based”  estimates  helps  them  to 
see  you’re  “walking  your  talk” 

•  Don’t  forget  that  different  mechanisms  are  likely  to  be 
needed  for  different  stakeholders  in  your  value  network 
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Identifying  Transition  Risks 
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Sources  of  Transition  Risk 

Most  transition  risks  come  from  misfits  between  the 
characteristics  of  the  technology  and  the  characteristics  of 
the  users  who  are  asked  to  adopt  it.  Common  transition 
risk  areas  include  misfits  between  the  technology  and: 

•  Business  strategy 

•  Organizational  work  practices 

•  Reward  system 

•  Skills 

•  Values 

•  Sponsorship 

•  Structure 

•  Technology  adoption  history 
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The  Good  News.... 

CMMI  corrects  many  of  the  problems  and  defects  that 
we  have  known  were  in  SW-CMM  1.1  for  some  time 
but  couldn’t  fix  until  a  new  model  version  could  be 
released 

The  transition  characteristics  of  SW-CMM  and  CMMI 
are  pretty  much  the  same  for  several  of  the  transition 
risk  factors — most  of  the  differences  are  expansions  in 
scope  rather  than  focus 

What  this  implies  is  that  organizations  who  are  at  low 
risk  with  the  transition  risk  factors  for  SW-CMM  should 
be  at  low  risk  with  those  risk  factors  for  CMMI 
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Some  Notes  on  Differences. ...Mostly 
Expansions  of  Scope 

•  Business  strategy — CMMI  expands  the  business  strategy 
focus  of  CMMI  into  projects  that  go  beyond  software 

•  Organizational  work  practices — biggest  area  of  difference 

CMMI  expands  the  focus  on  work  practices  related  to 
measurement,  engineering,  risk  management,  and  integrated 
product  development  at  minimum 

•  Reward  system 

•  Skills — expanded  set  of  engineering  skills  is  needed  to  support 
some  aspects  of  CMMI 

•  Values 

•  Sponsorship — sponsorship  needed  typically  extends  beyond 
software 

•  Structure — other  parts  of  the  organization  will  typically  be 
involved 

•  Technology  adoption  history — successful  SW-CMM  adoption 
history  should  be  helpful  in  CMMI  adoption 
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Homework 

Think  about  risks  related  to: 

•  The  value  network  you’ve  identified  and  their 
expectations 

•  The  transition  mechanisms  that  you  think  will  be 
needed  to  support  your  CMMI  transition 

•  The  transition  risk  factors  highlighted  in  this 
section 

Your  CMMI  transition  plan  can  be  started  with  risk 
mitigation  actions  to  reduce  the  probability  and/or 
effects  of  the  risks  you  identify 
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Summary 
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Building  a  Transition  Strategy  for 
CMMI 

Key  Points: 

•  Understand  where  you’re  starting  from  in  terms  of  other 
model-based  improvement  efforts 

•  Understand  your  audience  (both  “old”  and  “new”  if 
starting  from  another  model) 

-  Building  a  value  network  with  the  CMMI®  Transition 
Team  as  the  hub  is  a  good  way  to  explore  this 

-  What’s  the  “fit”  of  CMMI  with  your  key  audiences? 

•  Understand  WHY  you  are  transitioning 

-  What  problem  will  CMMI  implementation  be  expected 
to  solve? 

•  Understand  what  you  can  leverage  from  previous  efforts 

-  We’ve  taken  a  stab  today  at  starting  this 
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Technology  Transition  Approaches 
Can  Help  You  to  Analyze  Your  SW- 
CMM  Implementation  and  How  It  Can 
Support  Your  CMMI  Adoption 

Ones  I  hope  you’ll  remember  and  use: 
•Value  Networks 
•Transition  Mechanisms 
•Transition  Risks 


©  2003  by  Carnegie  Mellon  University 


Version  1.0 


page  70 


GamegieMellon 

Software  Engineering  Institute 

Pittsburgh,  PA  15213-3890 


Thank  You! 

For  PDF  version  of  this  presentation,  check  at 

www.sei.cmu.edu/ttp 

AFTER  Oct  24th 

For  other  CMMI  adoption  support  materials,  check  at 

www.sei.cmu.edu/cmmi 
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Trademark  Notice 


The  following  marks  are 
registered  in  the  U.S. 
Patent  and  Trademark 
office  by  Carnegie  Mellon 
University: 

Capability  Maturity  Model® 
Capability  Maturity 
Modeling® 

Carnegie  Mellon® 

CERT® 

CERT  Coordination 
Center® 

CMM® 

CMMI® 


The  Software  Engineering 
Institute  (SEI)  is  a  federally 
funded  research  and 
development  center 
sponsored  by  the  U.S. 
Department  of  Defense 
and  operated  by  Carnegie 
Mellon  University. 
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CURESM 

COTS  Usage  Risk 

EvaluationSM 

EPICSM 
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Integrating  COTS  Based 
Systems^ 

Framework  for  Software 
Product  Line  PracticeSM 
IDEALSM 
Interim  ProfileSM 
OARSM 

Options  Analysis  for 
ReengineeringSM 


Version  1.0 


OCTAVESM 
Operationally  Critical 
Threat,  Asset,  and 
Vulnerability  EvaluationSM 
PLTPSM 

Product  Line  Technical 

ProbeSM 

PSPSM 

Personal  Software 

ProcessSM 

SCAMPIsm 

SCAMPI  Lead  AssessorSM 
SCAMPI  Lead  AppraiserSM 
SCESM 
SEISM 

SEI-EuropeSM 

SEPGSM 

TSPsm 

Team  Software  ProcessSM 


page  72 


